Device connections might be flakey, but the update might still be happening in the background.

If the inflight update firmware uuid matches the device metadata then the update was likely a success.

Otherwise the delay in starting can cause it to miss some broadcasts, and make testing a bit harder.

This adds a new event that is sent to the orchestrator when the device is fully 'online' and has gone through the `after_boot` and device registration steps.

If the devices firmware matches the deployments, there is no need to trigger an orchestrator run

Since we now tell the deployment that a device assigned to it is online, we can place the "device finished updating" broadcast in the right place

This reduces subscribers to `deployment:#{id}` receiving a bunch of messages which mean nothing to them

Add a 10sec buffer between orchestrator runs.
This is done by using a `send_after` timer ref, tracking if another call has been made, and allowing for the buffer to be skipped during testing.

…es-hub/nerves_hub_web into distributed-deployment-orchestrator

A device now goes from `:connecting` to `:connected`, signifying
that it is ready to receive updates.

Using this different status allows us to tell the orchestrator to only
schedule update for devices that have "finished" connecting

…vice

This provides a nice cleanup in our new orchestrator and tests.

It's just a normal GenServer and doesn't know anything of `ProcessHub`, which is just a way of running it at scale.